home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / ospf / ospf-minutes-93mar.txt < prev    next >
Text File  |  1993-04-29  |  9KB  |  203 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4.  
  5. Reported by John Moy/Proteon
  6.  
  7. Minutes of the Open Shortest Path First IGP Working Group (OSPF)
  8.  
  9. The OSPF Working Group met on Tuesday, March 30th at the Columbus, IETF.
  10. The Minutes of that meeting follow.  The meeting began with a discussion
  11. of the six documents that the Working Group had in progress:
  12.  
  13.  
  14.   1. The latest draft of the OSPF V2 specification was reviewed.  The
  15.      only change that had been made since the last meeting was to handle
  16.      the following case:  A router becomes Designated Router, originates
  17.      a network-LSA, then later restarts with a different Router ID and
  18.      becomes Designated Router again.  At this point, the router
  19.      originates a network-LSA having the same Link State ID, but
  20.      different Advertising Router, than the previous network-LSA. The
  21.      fact that these two network- LSAs can both exist in the OSPF domain
  22.      concurrently can confuse the Dijkstra calculation.  Text has been
  23.      added to the specification ensuring that the network-LSA originated
  24.      before the last router restart will be flushed.
  25.      After some discussion, it was decided to submit the latest draft
  26.      (which had been published as an Internet-Draft) to replace RFC1247
  27.      at the current standards status (Draft Standard).
  28.  
  29.   2. The OSPF Trap MIB had remained unchanged, except for editorial
  30.      comments, since the last meeting.  It was decided to submit this to
  31.      be published as a Proposed Standard RFC.
  32.  
  33.   3. The OSPF NSSA area specification was reviewed.  A problem was found
  34.      in the aggregation of multiple type 7 LSAs into a single type 5
  35.      LSA, involving the choice of metric.  Two solutions were discussed:
  36.  
  37.        o Have the type 7 LSAs always take precedence, and
  38.        o Set the metric to be the largest of any of the component
  39.          metrics.  Rob Coltun will investigate these options further.
  40.  
  41.  
  42.   4. Osmund deSouza presented a document describing how to run OSPF over
  43.      Frame Relay.  The document describes how to split the Frame relay
  44.      PVCs into collections of OSPF Point-to-point networks and NBMA
  45.      networks.  A comment was made that treating PVCs as unnumbered
  46.      links was problematic, due to the inability to assign an ifIndex to
  47.      individual PVCs.  It was decided that after adding comments, the
  48.      document will be submitted for publication as an Informational RFC.
  49.  
  50.   5. No progress had been made on the OSPF MIB, which needs some
  51.      additions before it can be republished.
  52.  
  53.   6. No progress had been made on the ``OSPF Database Over-flow''
  54.  
  55.                                    1
  56.  
  57.  
  58.  
  59.  
  60.  
  61.      document.
  62.  
  63.  
  64. The ``OSPF for SIP'' Internet-Draft written by Christian Huitema was
  65. summarized as:  regular OSPF, running over IPv4, with two additional
  66. LSAs to import SIP information and an additional bit in the router-LSA
  67. to indicate SIP capability.  This was intended to allow a more or less
  68. seamless migration from IPv4 to SIP, after which a native OSPF for SIP
  69. would be defined.  Detailed discussion of the Draft was carried on in
  70. the SIP Working Group.  In fact, it was decided that all detailed
  71. discussions of OSPF in IPv7 would be carried on in the appropriate IPv7
  72. working groups.
  73.  
  74. Dennis Ferguson then presented an overview of his ``OSPF external
  75. attributes'' proposal, which is an addition to the OSPF<->BGP routing
  76. interchange and can be used as a substitute for Internal BGP. Dennis
  77. also presented operational statistics from the NSFnet that indicated his
  78. proposal would be quite efficient.  Discussion indicated that
  79. efficiency, measured in terms of the percentage of the database
  80. dedicated to this scheme, would decrease when CIDR was deployed.  Tony
  81. Li mentioned that it will also be necessary to know whether all routers
  82. participating in the ``OSPF external attributes'' are BGP-4 speakers, or
  83. whether some are BGP-3 speakers, in order to decide whether BGP
  84. aggregation should be done.  Most of the discussion then centered on the
  85. problem that, since the external attributes (type 8 LSAs) can only be
  86. flooded through supporting OSPF routers, it is possible that the
  87. database of external attributes could get out of synch with the type-5
  88. LSAs (which in turn could lead to problems in BGP routing).  Dennis
  89. suggested three ways of dealing with this:
  90.  
  91.  
  92.   1. Choose the Link State IDs for type 8 LSAs in a random fashion, so
  93.      that lack of synchronization would be obvious.
  94.  
  95.   2. Potentially run Dijkstra a second time to ensure that there is
  96.      type-8 flooding connectivity between BGP speakers, or
  97.  
  98.   3. Change the document so that ``most'' routers must be capable of
  99.      flooding type 8 LSAs.  No decision was made on these options.
  100.      Finally, it was noted that a combination of Internal BGP and the
  101.      new ``OSPF external attributes'' cannot be run since the tag field
  102.      in the OSPF type 5 LSAs would then have two conflicting
  103.      requirements.
  104.  
  105.  
  106. Tom Pusateri presented an outline of a proposed RIP to OSPF transition
  107. document, based on a talk he gave at INTEROP. He solicited suggestions
  108. for additional items to cover (send to pusateri@cs.duke.edu).
  109. Suggestions given at the meeting were:
  110.  
  111.  
  112.   1. Warning against running OSPF and RIP in parallel.
  113.   2. Give an example of a real, non-trivial network and how to
  114.  
  115.                                    2
  116.  
  117.  
  118.  
  119.  
  120.  
  121.      transition it.
  122.   3. How to do address assignment.
  123.   4. How to decide what's in an area.
  124.  
  125.  
  126. Lastly, a conflict between OSPF and Router Requirements was mentioned.
  127. Router Requirements states that you can't follow the default route to
  128. get to subnets.  This rule doesn't work for OSPF stub areas, and several
  129. people mentioned that the rule, while consistent with RIP, shouldn't
  130. really apply to other protocols.  A different rule, along the lines of:
  131. ``when aggregating, create a discard route for the aggregate'', was
  132. suggested.  Philip Almquist, the editor of the Router Requirements
  133. documents, was present and participated in the discussion.
  134.  
  135. Attendees
  136.  
  137. Philip Almquist          almquist@jessica.stanford.edu
  138. Dennis Baker             dbaker@wellfleet.com
  139. Fred Baker               fbaker@acc.com
  140. Jim Beers                Jim.Beers@cornell.edu
  141. Nutan Behki              Nutan_Behki@qmail.newbridge.com
  142. Richard Bjers            rich.bjers@uc.edu
  143. John Boatright           bryan_boatright@ksc.nasa.gov
  144. Robert Calderon          calderon@noc.ans.net
  145. Douglas Carson           carson@utcc.utoronto.ca
  146. James Cassell            jcassell@dsac.dla.mil
  147. Rob Coltun               rcoltun@ni.umd.edu
  148. David Conrad             davidc@iij.ad.jp
  149. Wayne Cullen             wnc@netlink.com
  150. Kurt Dobbins             kurtdob@ctron.com
  151. Kishan Dudkikar          kishan@icm1.icp.net
  152. Dennis Ferguson          dennis@ans.net
  153. Paul Franchois           paulf@bldrdoc.gov
  154. Christine Fredenburg     cfredenburg@dsac.dla.mil
  155. Vince Fuller             vaf@stanford.edu
  156. Darren Griffiths         dag@ossi.com
  157. Patrick Hanel            hanel@yoyodyne.trs.ntc.nokia.com
  158. Jeffrey Honig            Jeffrey_C_Honig@Cornell.edu
  159. David Jacobson           dnjake@vnet.ibm.com
  160. Zbigniew Kielczewski     zbig@eicon.qc.ca
  161. John Krawczyk            jkrawczy@wellfleet.com
  162. Duane Kuang              duanek@kalpana.com
  163. Tony Li                  tli@cisco.com
  164. Robin Littlefield        rlittlef@wellfleet.com
  165. Glenn Mackintosh         glenn@canet.ca
  166. Jamshid Mahdavi          Mahdavi@a.psi.edu
  167. Glenn Mansfield          glenn@aic.co.jp
  168. Jun Matsukata            jm@eng.isas.ac.jp
  169. James Miner              jjm@fibercom.com
  170. John Moy                 jmoy@proteon.com
  171. Julie Myers              jmyers@network.com
  172. Shannon Nix              sdn@netlink.com
  173. Zbigniew Opalka          zopalka@agile.com
  174.  
  175.                                    3
  176.  
  177.  
  178.  
  179.  
  180.  
  181. Ayal Opher               aopher@synoptics.com
  182. Joe Pagan                jrp@afterlife.ncsc.mil
  183. Thomas Pusateri          pusateri@cs.duke.edu
  184. Edward Reed              eer@cinops.xerox.com
  185. Ben Robinson             ben_robinson@vnet.ibm.com
  186. Benny Rodrig             4373580@mcimail.com
  187. Manoel Rodrigues         manoel_rodrigues@att.com
  188. Hal Sandick              sandick@vnet.ibm.com
  189. Shiva Sawant             shiva@synoptics.com
  190. Kanan Shah               kshag@cmf.nrl.navy.mil
  191. Andrew Smith             asmith@synoptics.com
  192. Martha Steenstrup        msteenst@bbn.com
  193. Steve Suzuki             suzu@fet.com
  194. John Tavs                tavs@vnet.ibm.com
  195. Marek Tomaszewski        marek@net.com
  196. Kannan Varadhan          kannan@oar.net
  197. Linda Winkler            lwinkler@anl.gov
  198. Jane Wojcik              jwojcik@bbn.com
  199.  
  200.  
  201.  
  202.                                    4
  203.